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Mission Control Center (MCC) Background 

The concept of Mission Control was envisioned by Christopher Columbus Kraft 
in the 1960’s. Instructed to figure out how to operate human space flight safely, Kraft 
envisioned a room of sub-system experts troubleshooting problems and supporting 
nominal flight activities under the guidance of one Flight Director who is responsible for 
the success of the mission. To facilitate clear communication, MCC communicates with 
the crew through a Capsule Communicator (CAPCOM) who is an astronaut themselves. 
Gemini 4 was the first mission to be supported by such a MCC and successfully 
completed the first American EVA [1]. 

The “MCC” seen on television is called the Flight Control Room (FCR, 
pronounced “ficker”) or otherwise known as the “front room.” While this room is the 
most visible aspect, it is a very small component of the entire control center. The Shuttle 
FCR is kn own as the White FCR (WFCR) and Station’s as FCR-1. (FCR-1 was actually 
the first FCR built at JSC which was used through the Gemini, Apollo and Shuttle 
programs until the WFCR was completed in 1992. Afterwards FCR-1 was refurbished 
first for the Life Sciences Center and then for the ISS in 2006.) 



Along with supporting the Flight Director, each FCR operator is also the 
supervisor for usually two or three support personnel in a back room called the Multi- 
Purpose Support Room (MPSR, pronounced “mipser”). MPSR operators are more 
deeply focused on their specific subsystems and have the responsible to analyze patterns, 
and diagnose and assess consequences of faults. The White MPSR (WMPSR) operators 
are always present for Shuttle operations; however, ISS FCR controllers only have 
support from their Blue MPSR (BMPSR) while the Shuttle is docked and during critical 
operations. Since ISS operates 24-7, the FCR team reduces to a much smaller “Gemini” 
team of 4-5 operators for night and weekend shifts when the crew is off-duty. 

The FCR is also supported by the Mission Evaluation Room (MER) which is a 
collection of contractor engineers who provide analysis and long-tenn troubleshooting 
support. Each MER operator is an expert in a very small portion of a sub-system and 
each FCR console usually interfaces with several MER positions. 

Contextual Inquiries 

The goal of a contextual inquiry is to gain a better understanding of a subject, 
their work tasks and their environment by actually going to where they work and 
observing them. Unlike ethnography, which in the strictest form champions an un- 
interrupting silent observer, contextual inquiry encourages a mentor/mentee relationship 
which can help a designer more quickly better understand the needs of their subject. The 
benefit of a contextual inquiry is that the researcher can observe and question a subject 
while they are immersed in their work. Unlike an interview method, the subject does not 
have to try to recall how they carry out their tasks. All they have to do for a contextual 
inquiry is explain what they are doing as they do it. If the observer has adopted a 



mentor/mentee relationship, then they can probe with questions to help gain a full 
understanding of the subject’s task [2]. 

The following discussion is the result of a contextual inquiry for a WMPSR 
Guidance Navigation and Control (GNC) Support Officer and their ISS BMPSR 
counterparts, HAwKI. The call sign “HAwKI” is derived from the fundamental concepts 
of their position’s responsibilities: Momentum (H), Attitude (A), Angular Rate (w), 
Kinetic Energy (K) and Moment of Inertia (I). GNC Support’s corresponding FCR 
position is called “GNC” and HAwKI’s is ADCO (Attitude Determination and Control 
Officer). The MPSR operators perform most their subsystem’s standard operation tasks 
including analysis computations, building and sending commands, documentation and 
research. Since the MPSR performs these tasks, the FCR operator is available to focus 
on integration with the other members of the flight control team. Thus, ISS and SSP 
MCC operations are more different at the MPSR level than the FCR level. 

In order to perfonn the contextual inquiries I shadowed a GNC and HAwKI 
operator during two separate training sessions of a simulated Shuttle docking with ISS. 
The docking phase is the most intense orbit mission timeframe for both GNC and ADCO 
and is also the mission phase requiring the most integration with other systems. Each 
operator was “certified,” meaning they have completed all training requirements for their 
position and each has previous real-time mission experience. For comparison with ISS, 
only the orbit mission phase of the shuttle was considered. For reference, the reader 
should note that GNC Support only works the orbit phase. During ascent and entry, GNC 
is supported by two MPSR operators: Control and Sensors. 



GNC Support 

The SSP GNC console is responsible for all the hardware that provides input to 
the guidance, navigation and control software and controls the vehicle. GNC system 
responsibilities include the inertial measurement units (IMU), engine trust vector 
controllers, accelerometer assemblies, digital auto pilot (DAP) software, rate gyro 
sensors, aerosurface actuators, hand controllers, star trackers, TACANs, microwave 
landing system, radar altimeters, trajectory control sensor (TCS) and Global Positioning 
System (GPS) receivers. 

“Artifacts” are tangible things created for use or aids to accomplish work. [3]. An 
artifact model depicting a physical representation of the GNC support console is shown 
in Figure 1. 



Figure 1. Artifact Model for GNC Support depicting a physical representation of 

the console setup. 

The primary feature of the GNC support console are four monitors which connect 
to the SSP GNC server which are part of the larger MCC network. On these four 







monitors, the operator can arrange the digital telemetry displays as they desire, however, 
most operators set up their configurations similarly due to common training. 

Monitor 3 is the prime monitor which is used to display the prime GNC Orbit 
high-density display (Figure 2). This display has high level telemetry from the prime 
orbit hardware systems including the orbital main engine system (OMS) TVC, IMUs, 
DAP, star trackers and an attitude summary. 
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Figure 2. GNC Orbit main telemetry display from a simulation. 


From the GNC Orbit display, the operator can access more detailed telemetry 
from the various systems by clicking on the corresponding buttons. Under the IMU 
section, the buttons labeled “1”, “2”, “3”, “RSTRT DRIFT” and “RSTRT ACCEL” run 


computation programs to help the operator identify the subtle failure modes of the IMU 
hardware. The numbered buttons resolve the IMU attitude and velocity telemetry into the 
reference frames of each IMU and the DRIFT and ACCEL buttons restart an integrated 
calculation which is used to identify a drifting IMU platform, biases and scale factors. 



The organization of the GNC Orbit display shows that GNC operators view their 
system as an organization of hardware components. Each display (or portion of a 
display) is dedicated to a specific sub-system. The benefit of this organization is that no 
matter how the hardware is being used and regardless of the current task, the flight 
controller can look in the same place for sub-system information. The main display also 
shows which sub-systems GNC operators view as the most critical since several hardware 
components have no telemetry on this display. The center of the display is the DAP since 
it is important that control of the vehicle is always maintained. This is indicative of the 
GNC console troubleshooting strategy to always make sure you have control, then 
troubleshoot problems. The largest portion of the display is IMU information which 
requires a substantial portion of the operator’s awareness due to the subsystem’s 
importance and many subtle failure modes of the hardware. The display is also organized 
with navigation aids and sensors on the right, guidance indications in the middle and 
control hardware on the left. 

The information placed on the GNC Orbit display represents high-level 
indications from the sub-systems providing the operator with an overview of the 
hardware’s perfonnance. Should any of this telemetry indicate a problem, the operator 
would open a more detailed display for the hardware. Grouping the most descriptive, 
high level telemetry items on a single display allows the operator to gather overall system 
awareness with a relatively short scan pattern. 

The display also contains the specific vehicle identification number, mission 
number, mission elapsed time (MET, time since lift off) and GMT. This enables 



hardcopies of the display to be tracked to specific events of a given flight and aids with 
documentation. 

The structure of GNC displays is very simplistic since they were originally 
designed for significantly less capable computers. When the SSP upgraded to the 
WFCR, the display format was not changed to prevent having to retrain flight controllers. 
The black background with light colored text also makes the displays look like the 
original displays. 

According to Bainbridge, “it is impossible for even a highly motivated human 
being to maintain effective visual attention towards a source of information on which 
very little happens, for more than about half an hour” [4]. Nominally during a mission 
there are frequent long periods of little activity for the GNC system especially during 
crew sleep, when the ISS is in attitude control and during robotic and EVA operations 
when GNC systems do not change configuration often. To aid the operator’s monitoring 
function, GNC runs several programs to help identify failures. Limit manager programs 
change the color of telemetry on the display when it exceeds predetennined bounds. 
Telemetry from units powered off or in “standby” mode are grayed out or made purple to 
not distract attention from operator. This colorization also causes a significant change 
when a unit power fails to drawn the operator’s attention to the failure. Many alert 
messages are also accompanied by alert tones in the headset. 

To aid monitoring of the telemetry stream, GNC also has an automated events 
monitor called ELOG which creates a running log of events. Most operators place this 
display directly below the GNC Orbit display on Monitor 3. ELOG looks for pre- 
determined events in the telemetry stream and enunciates messages that these events have 



happened. For example, when the crew places the Shuttle into an inertial (INRTL) 
attitude hold ELOG will display a “DAP INTRL” message for the operator. ELOG is 
also used as a GNC events record for an entire mission. With each message enunciation 
the MET and the GMT time is recorded. The limitation of ELOG is that it only 
enunciates events for which it has been preprogrammed to recognize. 

Next to ELOG on Monitor 3, the onboard fault summary (OFS) is displayed 
which keeps a running record of fault messages enunciated onboard. Some of these 
messages are nominal, for example messages generated as the crew powers on and off 
equipment. ELOG messages capture many more events than the OFS messages 
enunciated for the crew since ELOG looks for very specific GNC related actions. 

“RT Plots” are placed on Monitor 4 which show selected telemetry items on 
graphs which scroll with time. The operator can add limit lines to these graphs, scroll 
backwards to see previous trends and events and add prediction lines. The most 
commonly graphed telemetry are attitude rates, deadbands, IMU telemetry and drift and 
OMS TVC gimbal positions to monitor control during on orbit burns. 

Monitor 1 is also most often used for RT plots to monitor the control phase planes 
of the shuttle DAP. The use of Monitor 1, however, varies during the orbit phase. 
During rendezvous, it is used to display TCS information. While docked with station, it 
is used to for ADCO displays since most often the ISS is in attitude control and the 
majority of GNC’s hardware is not being actively used. 

Monitor 2 is used to run a program called “CRANS” which is a series of 100+ 
lights that turn various colors for different events. For example, if the main (MN) bus A 
of the shuttle failed, all the corresponding MN A box lights would turn red. CRANS also 



shows when any of the Shuttles RCS jets are tiring. Monitor 2 is also used to display a 
series of clocks which count down to upcoming events and display GMT and MET time. 
Finally, a star tracker field of view graph is commonly placed on Monitor 2 to watch the 
star tracker’s internal camera lock on stars and track them across the sky. 

The GNC operators can also run several analysis programs on the console 
workstation which decrease the number of hand calculations they must perform to 
minimize human error. For example, one program converts attitudes into different 
reference frames, another detennines which stars will be visible by the Shuttle’s star 
trackers during a specified orbit. The workstation also has several applications which 
generate command loads that can be uplinked to the vehicle. These are discussed in 
greater detail below. Finally, through the workstations the FCR and MPSR operators can 
send screenshots of data to each other and view the same workstation documents, such as 
command loads. 

The primary means of communication in MCC is through headsets. The use of 
headsets decreases ambient noise and allows communication between consoles which are 
located all around the MCC complex. The operator’s headset plugs into either headset 
jack at the ends of the console desk. The Digital Voice Intercom Subsystem (DVIS) 
panels on either end of the console are used to select which loops the operator is listening 
to and which loop the operator is enabled to talk on. Some loops, such as the “air-to- 
ground” which is the loop for the CAPCOM and the crew talk to each other, can only be 
monitored by other flight controllers. The DVIS panel allows an operator to monitor up 
to 24 loops at time, however, on average GNC support monitors approximately 10 loops. 



The operator can talk on a loop by depressing a switch on their headset or by pressing 
down on a foot pedal. The use of communication loops is further discussed below. 

The personal computer is a Microsoft Windows PC which is used for e-mail, 
typing up shift handover reports, generating official “Flight Notes” messages for the rest 
of the control team, creating anomaly reports (ARs) which officially document in-flight 
problems and writing CHITS which is the formal documentation for communications 
between the operations and engineering teams. On the PC, the operator can also view 
JEDI (Joint Execute Package Development and Integration) messages which are 
electronic documents uplinked to the crew. These messages include flight plan updates, 
procedures and summary information. 

TCS is an unusual hardware since it is not formally integrated into the Shuttle. 
Instead, TCS runs from a Window’s laptop in the Shuttle middeck and its telemetry is 
brought down along with the payload data instead of through the main telemetry streams. 
As such, GNC Support has the capability to run a ground version of the TCS command 
software on their PC. The ground copy of the software displays the real-time telemetry 
the crew is viewing onboard with their laptop, however, the ground software can only 
monitor telemetry and cannot generate TCS commands. 

The television is used to view MCC closed-circuit video of the FCR and 
downlinked video from the Shuttle and ISS. The television is also used to monitor real- 
time position plots such as relative motion plots of the ISS and Shuttle during 
rendezvous. Placing these videos and plots on the closed-circuit TV system allows 
access to all MCC operators without taking up valuable workstation resources. 
Downlinked videos also provide operators with increased situational awareness 



especially during extra-vehicular activities (EVAs, or space walks) and robotic 
operations. 

The GNC MPSR consoles are the only consoles to have a procedure stand. These 
stands were built by members of the group to hold up binders of procedures. They 
provide a convenient place to put procedures which can be viewed by the operator. The 
console desk has a sheet of plexiglass which covers many quick reference aids. These 
aids are notes made by the group for commonly referenced information. The procedures 
stands and plexiglass are two ways in which GNC flight controllers have modified their 
environment to assist with there job. 

There are approximately 20 binders of procedures (called Flight Data File (FDF)) 
and over 30 binders of reference information located behind the GNC Support console. 
The procedures are organized by flight phase and intention. For example, there are 
binders specifically for ascent, entry and orbit operations. Each mission phase has a 
nominal operations book, a malfunctions book and a “pocket” which is for time critical 
off-nominal procedures. There are also procedures books specifically for EVA, 
rendezvous, robotic operations, the mission timeline (“flight plan”) and on-board 
reference manuals. An example of a SSP flight plan page from STS-115 is shown in 
Figure 3. From looking at the flight plan, controllers can determine if scheduled 
activities will occur during orbital day or night, which crew member will perform the 
activities, the attitude and if there will be clear communication with the vehicle. Among 
these binders are hardcopies of previous post-flight mission reports, detailed description 
of the onboard software, reference schematics called SSSH (the Space Shuttle Systems 
Handbook), system briefs and standard console procedures (SCPs) which document step- 



by-step instructions for the operation of the console. Each console also has a hard copy 
of the program flight rules which document predetermined responses for various on orbit 
events. 


At the end of a busy mission phase, the console often looks like an explosion of 
paper and binders with procedures opened to various pages and spread all over the 
console. With procedures in one book often referencing another and all the references 
and procedures required for nominal operation, the operator can quickly find themselves 
in several different FDF books at one time. This can quickly lead to a cluttered console. 
This clutter can also serve to help the operator. Often humans spread paper over their 
desks to serve as a physical representation of what is going on in their heads [5]. For 
example, this personal organization can remind themselves of system issues they have to 
address or upcoming procedures they must monitor. 
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Figure 3. Shuttle flight plan page example from STS-115. [11] 


Throughout each mission, GNC Support and GNC each maintain a flight 
documentation binder which includes handwritten shift logs, copies of shift handover 
reports documenting a summary of the shift’s activities and present system status, hard 
copy of telemetry from specific points in the mission and documentation of mission 
events. These binders are used by the oncoming teams to get caught up with activities 
since their last shift and are maintained by the group as a reference document for that 
mission’s activities. 

Another important artifact near the GNC console is the refrigerator, microwave 
and vending machines. Most flight controllers have shifts averaging between 8 and 10 
hours with only 5-10 minute breaks every few hours. Thus, having available food is 
important not only to keep controllers awake but sustain them through long shifts. 

The console workstation serves as one way GNC support and GNC can exchange 
information. Since the WMPSR is located right outside the door of the WFCR, these two 
operators often share infonnation face to face as well. The flow of information internal 
to the GNC discipline and with outside parties is depicted in the flow model shown in 
Figure 4. 
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Figure 4. Flow Model for GNC Support. 

During the orbit phase of flight, the GNC console operators primarily interface 
with the Flight Director (“FLIGHT”), the propulsion operator (“PROP”) and the data 
processing systems (“DPS”). PROP is responsible for the onboard engines and jets. 
Their corresponding MPSR positions are “OREO” (OMS/RCS Engineering Officer) and 
“Consumables” which manages the onboard propellant. DPS is responsible for the 
onboard computers, the shuttle operating system and the serial data bus network. DPS 
has one MPSR position called “DPS Support”. 








GNC interfaces with several MER positions but most often with MER NAVAIDS 
(responsible for navigation hardware), MER GNC (responsible for DAP analysis), MER 
IMU, and MER Flight Control. 

Similar to their FCR counterparts, GNC Support also directly exchange 
information with other MPSR team members, the GNC MER, on-coming and off-going 
GNC shift teams. While the flow model readily depicts the FCR operator’s responsibility 
for the majority of integration, MPSR operators also exchange information of system 
status to assist with integration, and troubleshoot problems. For example, if GNC 
Support sees one of their systems has power failed, they will check with Electrical Power 
Systems (EPS) Support to see if they noticed a short on the corresponding electrical bus. 

In order to effectively support their FCR operator, MPSR operators must be aware 
and monitor communication of their FCR with other consoles. This decreases the need to 
repeat information and increases situational awareness. MCC operates in a “chain of 
command” from the MPSR, to the FCR console to the Flight Director and out the SSP 
program Mission Management Team (MMT). Thus, clear communication is imperative 
since there are often several degrees of separation between the start and end of a 
communication line. Adding to the difficulty, most communication occurs via the DVIS 
system eliminating the benefits of face-to-face communication. The SPAN console 
position is usually staffed by a manager (often a former flight controller) who is 
responsible for integrating communication between the flight control team and the MER 
and managing AR documentations. This position helps insure flight events are properly 
documented for future reference and that necessary members of the SSP community are 
aware of events as required. 



Notice on the flow model that GNC only receives information from the Shuttle 
and does not have the ability to send information to the vehicle. When GNC operators 
build a command on their workstations, the GNC FCR operator requests uplink 
pennission from FLIGHT and then the Instrumentation and Communications Officer 
(INCO) performs the actual uplink of the command. The GNC console only uplinks a 
handful of commands to the vehicle during a typical fourteen day mission. Most system 
actions are dependent upon the crew flipping switches or entering commands into the 
shuttle computers. 

The flow model depicts the large number of groups with which operators must 
coordinate activities. The large number of players inside of MCC also complicates 
communication by making sure all parties necessary are aware of information and 
knowing who to contact. The most difficult aspect of obtaining certification as a flight 
controller is communication. It takes hundreds of hours of practice to master monitoring 
loops, knowing when and to whom to relation information and how specific the 
information to be. Garret and Caldwell of Perdue University conducted a contextual 
inquiry of the ISS Gemini operators and found that management of information flow with 
MCC was critical due to the physically distributed nature of operators within the complex 
[6]. Mastery of information flow paths is important to ensure effective use of resources 
and that no controller makes a final decision independent of the rest of the time. 

Garret and Galdwell identified four types of information that are exchanged in 
MCC [6]: 

1 . Software - internal to a single cpu on either ground or the vehicle exchanged 
through the workstation computers 

2. Command - antenna configuration / availability and command uplinks sent 
from MCC to the vehicle 



3. Network - data and telemetry streams between vehicle and computers on the 
ground as well as between each of the computers on the ground 

4. Knowledge - voice loops over DVIS (managed by FD) (main instrument for 
knowledge sharing between spatially distributed controllers / astronauts) 

Of the information types, Garret and Galdwell identified knowledge as the most difficult 
to maintain cognizance of, again indicating the communication challenges inside MCC. 

The large number of groups in MCC makes it impractical for operators to have 
their consoles in the same room as everyone they integrate with, however as stated, 
physically separating operators is a challenge for communication. Figure 5 provides a 
physical representation of the layout of MCC. 
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Figure 5. Physical Model of MCC (not to scale). 

Arrows depict the most frequent consoles with which GNC Support exchanges 
information. Dotted lines depict communication which is difficult to achieve face-to-face 



due to physical separation. The physical model shows that the WFCR and WMPSR are 
located adjacent to each other which allows for limited face-to-face communication 
between GNC and GNC Support. The BMPSR, however, is located on a separate floor 
from FCR-1. Note that both the SSP and ISS MERs are on completely different floors 
from the other rooms. In order to allow operators direct communication with another, 
MCC relies on the DVIS system. 

Due to the large spatial separation between operators, the physical model does not 
provide a good overview of console interaction. A model of the DVIS system is more 
informative (Figure 6). Watts, Woods, Corban and Patterson of Ohio State University 
conducted an ethnographic study to determine how the DVIS voice loops act as 
cooperative aids in MCC [7]. As a result of their research, they developed the following 
model of the voice loop structure from the perspective of a FCR operator. The model 
depicts the Flight Director’s coordination with the FCR team on the “Flight Loop,” that 
the CAPCOM only can talk on the Air/Ground loop to the crew, the FCR operators 
communicate with their MPSR counterparts via “Support Loops” and an example of the 
conference loops organized by discipline in the FCR (called “MOCR” loops). For 
example, GNC and PROP share a common FCR conference loop. There is also a 
conference loop for MPSR positions to coordinate with each other and a loop for each 
discipline to coordinate with their MER counterparts (These loops are not depicted in the 


model). 



Conference loops 



Figure 6. Model of voice loop structure for the SSP FCR and MPSR. [7] 

The structure of the voice loops parallels the chain of command structure of 
MCC. The multiple loop system enables simultaneous conversations among flight 
controllers, however, this means that flight controllers must be able to monitor parallel 
conversations - a difficult task developed during training. To facilitate loop 
communication, MCC has adopted a loop protocol. To call an operator, a flight 
controller first states the name of the position they wish to call, their name and the loop 
they are on. Usually the calling operator will wait for a “go ahead” call from the position 
they are establishing communication with. For example, ADCO wanting to talk to GNC 




would say “GNC, ADCO on your MOCR.” It is implied any call to FLIGHT is on the 
Flight Loop, so that loop is not stated. 

All flight controllers from a discipline constantly monitor at least the air to ground 
loops, the flight loops of both ISS and SSP when in dual operations, their conference loop 
and their support loop. However, most controllers will monitor the conference loops 
which indirectly affect their system. For example, GNC monitors “MOCR DYN” which 
is the conference loop for Rendezvous and the Flight Dynamics Officer (FDO, 
pronounced “fido”) during rendezvous. 

The ability to monitor several loops at once is an important strategy for ensuring 
flight controllers have situational awareness of activities over the entire vehicle. The 
ability to listen to discussions on the loops allows controllers to pick up relevant events 
and activities without disrupting their ongoing work within the scope of their 
responsibility. Dourish and Bellotti [8] refer to this function as a passive awareness 
mechanism and Woods [9] calls it preattentive reference. By monitoring other loops, 
flight controllers can dynamically and opportunistically change their attention and 
activities with response to the change state of the shuttle systems [7]. 

Monitoring loops enable controllers to anticipate problems in their own system 
and be prepared for future actions especially since shuttle systems are interconnected. 
“Anticipation has also been found to be important in control rooms of other domains in 
which teams coordinate to handle high-tempo, uncertain situations” [5]. Anticipation is 
important because it allows controllers to synchronize their communication and actions 
over time. For example, if a failure occurs in a subsystem, the flight director will ask 
related subsystem controllers about the impacts of that failure on their systems. When 


controllers hear about the failure on the flight director's loop, they can anticipate 
questions from the director, and prepare to answer them without delay [7]. No mission is 
routine. Depending on the mission, about 30 to 90% of the mission activities need to be 
replanned while the mission is being conducted [10]. 

To aid a flight controller’s ability to monitor loops, loops that are “enabled” to 
talk on have increased volume. Controllers can also program their DVIS panels to 
monitor specific loops at “high monitor” which increases the loop’s volume even when 
the loop is not talk enabled. This volume capability, however, is very limited especially 
since loop volume is directly affected by the volume at which the speaker talks. 

Figure 7 shows a sequence model depicting the typical actions taken by a GNC 
Support operator to resolve a problem onboard shuttle. A sequence model captures the 
most basic information about work practices including the intents of participants [3]. In 
the example of Figure 6, the trigger is a failure which occurs on board which is then 
noticed by the flight controllers. However, the trigger could also be the crew calling 
down to inform MCC of an abnormality. Steps in red have direct participation by GNC 
Support. The lightning bolts indicate steps which have the potential for “breakdowns” 
between them [3]. Due to orbital geometry, Shuttle does not always have a good line of 
sight to a TDRS communication satellite causing period loss of signal (LOS) which is a 
drop out of communication and/or telemetry. If a problem occurs during LOS, MCC will 
not be aware of it until acquisition of signal (AOS). If the problem does not require 
immediate attention and the crew is not available, then time has to be scheduled for the 
activity to be performed. Troubleshooting/resolution activities are often schedule for the 
end of the crew day but sometimes can be scheduled for many days in the future 


depending upon the criticality of the failure. The other possible delay can occur if the 
resolution requires a command and MCC is in LOS. The command cannot be uplinked 
until AOS. 



Figure 7. GNC Sequence model for resolution of onboard problems. 

The above sequence model shows that GNC cannot uplink their own commands. 
For the shuttle, flight controllers build the commands on their workstations but INCO 


performs the actual uplink. The shuttle has very limited command capability so the vast 
majority of problems require the crew to physically type in item entries to the computer 
or throw switches. Thus with the Shuttle, the crew is prime for all troubleshooting and 
system reconfiguration activities. 

HAwKI 

Operation of ISS is fundamentally different to previous NASA missions. The 
space station never comes back to KSC for repairs and for the first time, MCC must 
closely coordinate with IPs including Russia, Europe, Japan and Canada - all who have 
their own control centers [10]. If human space operations is not hard enough, ISS control 
teams also must deal with the following complications: 

■ Multi-lingual communication 

■ Cultural and tradition differences 

■ Operations in different time zones 

■ International operators who are viewing different data due to the use 
different computer models and procedures 

■ Training while operations are ongoing 

■ A vehicle that is still being constructed 

■ Limited up-mass capability 

Despite the many additional challenges, many aspects of operations at NASA’s ISS MCC 
(MCC Houston, “MCC-H”) are very similar to that for the Space Shuttle. 

ADCO and HAwKI are responsible for the Space Station’s attitude, momentum 
management for the four control moment gyros (CMGs) which provide attitude control, 
GPS, rate gyro sensors (RGAs). In addition to GNC hardware in the US Segment, 
ADCO also monitors telemetry from the Russian GNC hardware including star trackers, 
horizon sensors, GPS, thrusters, sun sensors, and magnetometers. 



An artifact model depicting a physical representation of the HAwKI support console is 
shown in Figure 8. FIAwKI’s console is physically and operationally similar to that of 
GNC Support and the other MPSR positions. The differences are summarized below. 


HAWKI 



Figure 8. Artifact Model for the HAwKI console. 


Monitor 2 is used for HAwKI’ s main displays called GNC Overview and Motion 
Control Group (MCG) Summary shown in Figures 9 and 10 respectively. 

GNC Overview is structured very similarly to GNC Orbit. The font is noticeably 
smaller in order to put more information on the display. The display’s structure strategy 
is also the same as GNC Orbit where the display is grouped by sub-system. Each blue 
box will bring up another display with more detail again the same as GNC Orbit. It is not 
surprising this display is so similar to shuttle displays because most of the original Station 
flight controller came from the Shuttle program. 
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Figure 9. ADCO/HAwKI’s GNC Overview display from a simulation. 


The GNC Overview display also includes information about the location of 
Station’s arrays. Since the array structure is very fragile, HAwKI must be aware of their 
orientation to kn ow which modes of attitude control are allowed. For example, the 
Shuttle is not allowed to fire its large attitude control thrusters while docked unless the 
arrays are locked in a protected orientation. It is ADCO’s responsibility to ensure the 
station is a good configuration for Shuttle attitude control. When ISS is ready, ADCO 
would notify GNC that the Shuttle can take over attitude control. 












This display also has information about the Russian (RS) Segment generated state 
vector. The US and RS segments both generate their own attitude state and the ISS can 
use either at a time. HAwKI must keep monitor two separate GNC systems and states. 

The MCG Summary display employs a very different strategy. The MCG display 
is intended to be viewed by the crew with their onboard laptops. Each system has a crew 
display to enable them view any telemetry and perform the same capabilities as the 
ground should it be required. 

MCG Summary is very visual to quickly provide the crew and flight controllers 
high-level system awareness. Each piece of hardware is represented by a box. If it is 
currently being used to detennine the attitude state, the box is blue. If the box has green 
comers, then the unit is powered ON. MCG Summary also provides a clear visual 
representation of the percentage of available CMG control torque momentum (control 
authority) currently being used to hold attitude. When the momentum exceeds 99%, the 
CMGs saturate and a loss of control (LOC) occurs. 

Due to the ease of this display, GNC Support also uses MCG Summary for 
situational awareness when the Shuttle is docked to ISS. 

Clicking on any hardware box will bring up another display with detailed 
information about that unit. The boxes at the bottom of the MCG Summary display bring 
up additional displays which provide the capability to send commands to the vehicle. 
Many of these displays are organized by the current activity and the display follows a 
procedure from top to bottom. An example of such a display used for docking is shown 
in Figure 11. 
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Figure 10. ADCO/HAwKI’s MCG Summary display from a simulation. 
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Figure 11. Docking command display example from a simulation 



The vast majority of steps in nominal procedures are performed via ground 
uplinked commands as opposed to the crew throwing switches on Shuttle. Thus as the 
Shuttle is docking to ISS (for example) HAwKI can monitor all required telemetry from 
the display in Figure 1 1 . Commands to the vehicle are sent by click on the oval buttons 
on this display. HAwKI can follow along in the procedure and send the command right 
in order as they move from top to bottom on the display. 

This display concept is very different than Shuttle. Instead of looking for 
indications on 4+ displays during docking as done by GNC, HAwKI (and the crew) have 
all the required information on one display. Thus, telemetry parameters are duplicated on 
several different displays. Organization displays in this manner increases the operator’s 
situational awareness to the parameters that are important at that point. The operator can 
bring up the specific procedure for the current mission activity and immediate see all 
important information instead of filtering the items from general displays as done on 
Shuttle. The method of organization also can serve as a memory aid for the operator 
because everything they need to verify is right in front of them on one display. Finally, 
for a given task, the operator can document all the relevant telemetry with one display 
hardcopy. This also can provide a quick snap shot of relevant parameters with at the 
same time instance. Not every procedure has its own display such as Figure 1 1 - only the 
commonly perfonned and complicated procedures. 

Each command must be built and stored on the server before the corresponding 
command button will work. Before each Shuttle flight, ADCO builds all the required 
commands as a group to limit the amount of work required during real-time operation. 
This allows the operators to take their time and eliminate errors which could occur when 



rushed during real-time operations. HAwKI will build any off-nominal commands that 
become necessary in real-time. 

Unlike Shuttle, each discipline has the ability to send commands to the vehicle 
and ground commanding is the prime way to perform nominal and off-nominal 
procedures. This allows the crew to be free to perform science and hands-on 
maintenance activities. As a result, the ISS flight control team sends orders of magnitude 
more commands than Shuttle during a given time period. 

HAwKI’ s monitors 3 and 4 are used for RT plots of current CMG total 
momentum used, commanded control torque, attitude errors, GMG gimbal angles, motors 
and the US Segment GNC rate errors. HAwKI’s uses Monitor 1 to build commands and 
thus, the monitor has a command history tracker and a command sentry window that 
displays “GOOD” or “BAD” depending upon if the ISS has good command uplink. The 
command sentry box is rather large (about an inch square) to help ensure the operator 
does not try to command the vehicle during periods of ratty communication. Monitor 1 
also has an events logger similar to ELOG and a Caution and Warning program similar to 
OFS. HAwKI used the television in the same manner as GNC Support. HAwKI does not 
have a display similar to GNC’s CRANS. 

The personal computer is much more important for an ISS flight controller than 
for Shuttle. In addition of the PC applications used by GNC Support, ISS flight 
controllers also view the majority of their procedures on the PC with an application called 
International Procedures Viewer (IPV) shown in Figure 12. Since HAwKI relies on 
electronic copies of their procedures, they do not have the need for the GNC Support’s 
procedure stand. While HAwKI does have backup hardcopies of their procedures, the 



electronic copies are the prime resource. Since the procedures are electronic, the ISS 
team can be assured they always have the most recent procedure version as oppose to the 
manual paper updates frequently performed by SSP flight controllers. Electronic 
procedures also enable easy updates to procedures onboard ISS via uplink instead of 
relying on paper copies which would have to wait for a launch vehicle to bring them to 
Station. 



Figure 12. Screen shot of IPV [12]. 

Station procedures called Systems Operations Data File (SODF) are organized 
into about 30 books primarily by sub-system. Procedure organization is simpler with ISS 
since it only has one phase of flight: orbit. Instead of being organized by flight phase, 
many station procedure books are referenced by system. For example, there is a book for 
assembly operations, EVA instructions, robotic operations, and MCG procedures. ISS 
procedures are complicated, however, by the fact ISS is still being constructed. The 


addition of hardware to the vehicle can make entire books of procedure invalid. Thus, 
many ISS procedures and flight rules have “expiration dates”. Station controllers also 
have reference books available including the International Space Station Systems 
Handbook (ISSSH) which is ISS’s version of the SSSH, SCPs, and flight rules. 

Since HAwKI relies on electronic procedures, they cannot make notes in the 
columns or set out a procedure as memory aid. Thus, HAwKI operators tend to keep a 
handwritten set of quick notes with things to do, procedure deltas to make and other 
reminders. 

ISS flight controllers and crew members also use a PC application called OSTPV 
(On-board Short Tenn Plan Viewer) which is an electronic version of a flight plan and 
contains the same basis information as the SSP flight plan. As the onboard crew 
completes tasks, they mark the task as completed in OSTPV. The crew can also leave 
notes for flight controllers in the program. The ground copy OSTPV is frequently synced 
with the onboard version allowing ISS controllers to see the progress of the crew and 
obtain crew notes without relying upon air-to-ground communication. The use of 
OSTPV makes the crew much more autonomous than on Shuttle. A screen shot example 
form OSTPV is shown in Figure 13 and can be compared with the SSP flight plan page 
example of Figure 3. 

In keeping with the electronic theme of ISS MCC operations, ADCO and HAwKI 
also keep their console logs via the PC instead of handwriting them as with GNC. The 
electronic log automatically time stamps entries as the operator types. The electronic 
logs are also more efficient for historical documentation purposes than with GNC’s 
mounds of paper in binders. 




Figure 13. OSTPV screen shot [12]. 

As with the console operations, information flow within the ISS flight control 
team is similar to that of Shuttle’s as shown in Figure 4. Since ADCO uses the PC to 
document flight activities, the computer becomes a key tool of information exchange 
between other shift teams. Also different on this Flow Model is the Russian Interface 
Officer (RIO) who coordinates between the US ISS MCC and that in Moscow. Similar to 
the SSP, ISS also has an MMT which is called the International Mission Management 
Team (IMMT). ISS program managers from all countries of participation serve on the 


IMMT. 



From FIAwKI’s point of view, the biggest difference between HAwKI and GNC 
Support is that it is very difficult for HAwKI to talk face to face with ADCO. As evident 
in the physical model shown above, the BMPSR is on a different floor from FCR-1. 
During the simulation I observed, ADCO and HAwKI never talked face to face. GNC 
and GNC support, in contrast, talk face to face about every two hours for a few minutes. 
Thus, ADCO flight controllers do not have the face time as with GNC to more easily talk 
through anomalies. 




Another difference with this flow model is that the arrow from the console to ISS 


is two way since HAwKI has the ability to directly command the vehicle. Since there are 
multiple consoles perfonning frequent commanding to the vehicle, all commands are 
coordinated on the DIVS loop “FMT Coord” which is monitored by all operators sending 
commands. When HAwKI is ready to send a command, they enable their position to 
command and click on the corresponding oval button. This brings up a pop-up window 
that says the command is unsafed and enabled. ADCO confirms the command is ready to 
HAwKI. HAwKI then checks goes to FMT Coord to ensure no other operators are 
sending a command and announces, “HAwKI sending command to (command purpose) 
on my mark, 3, 2, 1 mark.” HAwKI then sends the command via a button on the 
workstation on the mark. ADCO and HAwKI confirm the command is accepted by ISS 
and verify it in the telemetry. 

Adding to the difficulty of monitoring loops, many ISS loops periodically have 
Russian speaking with a translator. The bi-lingual nature of the loops, while minimized, 
adds to the loop clutter and increases the average volume level of the loops. 

HAwKI most often interfaces with the MPSR operators Systems Resource 
Manager (SRM) who is responsible for the positioning of the solar arrays and with the 
Resource Avionics Engineer (RAVEN) who monitors the onboard data and computer 
network. HAwKI interfaces with RAVEN to uplink commands which change software 
parameters, such as mass properties. These types of commands can only be uplinked by 
RAVEN. The physical layout of HAwKI and these consoles are shown in the physical 
model of Figure 5. 

The sequence model for resolution of onboard problems is shown in Figure 15. 




Figure 15. HAwKI Sequence model for resolution of onboard problems 


Since ISS flight controllers are prime for problem resolution, the sequence model 
for resolving problems is simpler than compared to that for Shuttle. The same 
breakdowns, however, are apparent within the model for LOS. 

A significant difference in the sequence for problem resolution, however, is the 
increased participation of the ISS MER. ADCO’s ISS MER counterpart is called GNC. 
Unlike GNC Support who performs the majority of analysis for the console, ADCO’s 
MER provides analysis support. For example, GNC Support will calculate any required 
IMU biases, IMU compensations, required OMS TVC trim loads, star line of sight vector 
uplinks, etc. GNC only contacts their MER when they have a question or if the internal 
parameters of the DAP need to be changed (this is a MER call). In contrast, ISS MER 
GNC calculates any required changes to CMGs, any attitude biases necessary, etc, and 
provides the analysis to ADCO/HAwKI which perform implementation. 
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